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ABSTRACT:  The  End-To-End  (ETE)  Test ,  conducted  under  the  auspices  of  the  Department  of  Defense  Joint 
Advanced  Distributed  Simulation  (JADS)  Joint  Test  and  Evaluation  (JT&E),  developed  a  synthetic  test  environment 
using  simulations  connected  by  satellite  that  can  be  used  for  future  testing ,  training  and  doctrinal  development.  This 
synthetic  environment  was  used  initially  to  assess  the  feasibility  of  using  distributed  simulation  to  conduct 
developmental  and  operational  testing  of  the  Joint  Surveillance  Target  Attack  Radar  System  (Joint  STARS).  As 
designed  and  built,  it  may  be  used  to  conduct  future  testing  of  systems  such  as  the  Block  II  Joint  STARS,  the  common 
ground  station  (CGS),  the  All  Source  Analysis  System ,  and  the  Block  II  Army  Tactical  Missile  System  (ATACMS). 

This  paper  will  describe  the  synthetic  test  environment,  the  design  considerations  involved  in  developing  the  synthetic 
environment,  the  modifications  of  the  distributed  interactive  simulation  (DIS)  standards  required  to  accommodate  the 
environment,  and  the  difficulties  involved  in  verifying  and  validating  the  environment.  Additionally,  some  of  the  pluses 
and  minuses  of  making  this  environment  high  level  architecture-compliant  in  the  future  will  be  discussed . 


1.  End-To-End  Test  Overview 

The  End-To-End  (ETE)  Test  was  one  of  the  three  tests 
conducted  under  the  auspices  of  the  Department  of 
Defense  Joint  Advanced  Distributed  Simulation  (JADS) 
Joint  Test  and  Evaluation  (JT&E).  JADS  was  chartered 
to  investigate  the  utility  of  advanced  distributed 
simulation  (ADS)  technologies  for  the  support  of 
developmental  test  and  evaluation  (DT&E)  and 
operational  test  and  evaluation  (OT&E).  The  program  is 
Air  Force  led  with  Army  and  Navy  participation.  Science 
Applications  International  Corporation  (SAIC)  provided 
contracted  technical  support  to  the  ETE  Test. 

The  ETE  Test  was  designed  to  evaluate  the  utility  of  ADS 
to  support  the  testing  of  command,  control, 
communications,  computers,  intelligence,  surveillance, 
and  reconnaissance  (C4ISR)  systems.  It  conducted  its  test 
and  evaluation  utility  evaluation  in  an  ADS-enhanced  test 
environment  using  the  Joint  Surveillance  Target  Attack 
Radar  System  (Joint  STARS)  as  the  system  under  test 
immersed  in  a  representative  C4ISR  environment.  The 
ETE  Test  also  evaluated  the  capability  of  the  JADS  Test 
Control  and  Analysis  Center  to  control  a  distributed  test 
of  this  type  and  to  remotely  monitor  and  analyze  test 
results. 


The  ETE  Test  used  distributed  interactive  simulation 
(DIS)  to  assemble  a  synthetic  environment  (SE)  for 
testing  C4ISR  systems.  The  intent  was  to  provide  a 
complete,  robust  set  of  interfaces  from  sensor  to  weapon 
system,  including  the  additional  intermediate  nodes  that 
would  be  found  in  a  tactical  engagement.  The  test  traced 
a  thread  of  the  complete  battlefield  process  from  target 
detection  to  target  assignment  and  engagement  at  corps 
level  using  ADS.  It  allowed  the  tester  to  evaluate  the 
entire  thread,  or  the  individual  contribution  of  any  of  the 
parts,  and  to  evaluate  what  effects  an  operationally 
realistic  environment  had  on  the  system  under  test. 

The  test  concept  was  to  use  ADS  to  supplement  the 
operational  environment  experienced  by  the  E-8C  and 
light  ground  station  module  (LGSM)  operators  by  adding 
additional  entities  to  the  battlefield  seen  by  Joint  STARS. 

Also,  by  adding  additional  elements  of  the  command, 
control,  communications,  computers  and  intelligence 
(C4I)  systems  that  Joint  STARS  interacts  with  and  a 
weapon  system  to  engage  targets,  the  test  team  could 
evaluate  a  thread  of  the  complete  battlefield  environment 
from  target  detection  to  target  assignment  and 
engagement. 


This  was  accomplished  by  adding  approximately  ten 
thousand  simulated  targets  to  the  live  targets  seen  by  the 
radar  on  board  the  E-8C  aircraft.  As  a  result,  a  battle 
array  approximating  the  major  systems  present  in  the  area 
of  interest  was  presented  to  the  operators  both  in  the  air 
and  on  the  ground.  A  network  was  then  constructed  with 
nodes  representing  appropriate  C4I  and  weapon  systems 
that  provided  a  more  robust  cross  section  of  players  for 
interaction  with  the  E-8C  and  LGSM  radar  surveillance 
operators. 

Several  components  were  required  to  create  the  ADS- 
enhanced  operational  environment  used  in  the  ETE  Test. 
In  addition  to  Joint  STARS,  the  ETE  Test  required  a 
simulation  capable  of  generating  thousands  of  entities 
representing  the  rear  elements  of  a  threat  force.  For  this 
purpose,  the  ETE  Test  team  selected  the  U.S.  Army’s 
Janus  simulation. 

Also,  a  simulation  of  the  Joint  STARS  radar,  called 
Virtual  Surveillance  Target  Attack  Radar  System 
(VSTARS),  that  simulated  both  moving  target  indicator 
(MTI)  radar  and  synthetic  aperture  radar  (SAR),  was 
developed  to  insert  the  simulated  targets  into  the  radar 
stream  on  board  the  E-8C  while  it  was  flying  a  live 
mission. 

The  target  data  were  sent  to  the  aircraft  for  processing  by 
VSTARS  using  satellite  transmission.  More  will  be  said 
about  this  later. 

Other  capabilities  used  to  support  the  test  included 
simulations  or  subsets  of  the  Army’s  artillery  command 
and  control  process  and  a  simulation  of  the  Army  Tactical 
Missile  System  (ATACMS). 

The  ETE  Test  consisted  of  four  phases.  Phase  1 
developed  or  modified  the  components  that  allowed  the 
mix  of  live  and  simulated  targets  at  an  E-8C  operator’s 
console  and  LGSM  operator’s  console.  Phase  2  evaluated 
the  utility  of  ADS  to  support  DT&E  and  early  OT&E  of  a 
C4ISR  system  in  a  laboratory  environment.  Phase  3 
moved  components  of  VSTARS  onto  the  E-8C  aircraft, 
ensured  that  the  components  functioned  properly,  and 
checked  that  the  synthetic  environment  properly 
interacted  with  the  aircraft  and  the  actual  LGSM.  Phase  4 
evaluated  the  ability  to  perform  test  and  evaluation  in  a 
synthetically  enhanced  operational  environment  using 
typical  operators. 

More  detailed  information  on  the  ETE  Test  can  be  found 
in  the  ETE  Test  reports  available  at 
http://www.JADS.abq.com.  (After  1  March  2000  refer 
requests  to  HQ  AFOTEC/HO,  8500  Gibson  Blvd  SE, 
Kirtland  Air  Force  Base,  New  Mexico  87117-5558,  or 


SAIC  Technical  Library,  2001  North  Beauregard  St.  Suite 
80,  Alexandria,  Virginia  22311 .) 

2.  ETE  Test  Synthetic  Environment 

The  Phase  4  ETE  Operational  Test  synthetic  environment, 
as  previously  described,  is  shown  in  Figure  2-1. 


SCDL  =  surveillance  control  data  link 

T1  =  digital  carrier  used  to  transmit  a  formatted  digital  signal  at  1.544 
megabits  per  second 

TRAC  =  U.S.  Army  Training  and  Doctrine  Command  Analysis  Center 
WSMR  =  White  Sands  Missile  Range,  New  Mexico 

Figure  2-1.  ETE  Test  Synthetic  Environment 

As  can  be  seen,  the  synthetic  environment  was  composed 
of  two  networks,  a  standard  wide  area  network  (WAN) 
for  passing  DIS  protocol  data  units,  voice,  and  Advanced 
Field  Artillery  Tactical  Data  System  traffic,  and  a  satellite 
link  for  passing  simulation  data  and  messages  to  the 
aircraft. 

Nothing  more  will  be  said  about  the  standard  WAN 
except  that  it  was  very  reliable  and  lightly  loaded  for 
reasons  to  be  discussed  later.  More  details  can  be  found 
in  the  ETE  Test  Phase  4  report  referenced  earlier. 

The  satellite  link  was  established  in  order  to  provide 
information  about  the  simulated  targets  to  VSTARS  on 
board  the  test  aircraft  (T3).  It  served  the  function  of  a 
virtual  radar  antenna.  Once  the  target  data  were  received, 
they  were  made  available  to  VSTARS  upon  demand, 
mixed  with  live  returns  as  appropriate  and  presented  to 
the  radar  surveillance  officers  on  board  the  aircraft.  The 
aircraft’s  surveillance  control  data  link  (SCDL)  enabled  it 
to  also  transmit  the  radar  reports  to  ground  stations 
located  on  Fort  Hood,  Texas. 


Using  this  technique,  an  operational  scenario  consisting  of 
ten  thousand  targets  located  in  western  Iraq  was  overlaid 
with  a  real  exercise  taking  place  at  Fort  Hood.  Fort  Hood 
could  target  any  of  the  targets  in  the  scenario  based  upon 
the  radar  reports,  engage  them  with  a  virtual  AT  ACM  S 
fired  from  Fort  Sill,  Oklahoma,  and  destroy  the  targets 
that  were  being  generated  at  the  U.S.  Army  Training  and 
Doctrine  Command  Analysis  Center,  White  Sands  Missile 
Range,  New  Mexico  (TRAC-WSMR).  Once  the  targets 
were  destroyed  by  the  ATACMS,  the  TRAC-WSMR 
operator  could  scatter  or  relocate  the  survivors. 

As  an  example,  one  of  the  engagements  during  the  test 
was  against  an  Iraqi  corps  headquarters  that  was  identified 
using  virtual  radar  reports  and  other  forms  of  intelligence. 
It  was  struck  with  several  ATACMS  that  caused  it  to 
relocate  to  an  alternate  site.  The  personnel  at  Fort  Hood 
tracked  the  movement  of  the  survivors  using  the  virtual 
MTI  radar.  They  waited  until  everyone  had  arrived, 
verified  the  new  position  with  a  virtual  SAR,  and  than  hit 
the  corps  headquarters  with  another  salvo  of  ATACMS. 

3.  Synthetic  Environment  Restraints  and 
Design  Considerations 

The  conceptual  model  for  the  ETE  Test  synthetic 
environment  was  conceived  almost  five  years  ago  and 
made  use  of  the  then  prevalent  methodology  for 
distributed  simulation,  distributed  interactive  simulation. 
Many  of  the  early  restraints  faced  by  the  ETE  Test 
designers  would  have  been  alleviated  had  the  high  level 
architecture  (HLA)  been  available.  This  will  be  discussed 
in  more  detail  at  the  end  of  this  paper. 

The  foremost  design  constraint  for  the  ETE  Test  synthetic 
environment  was  the  requirement  to  eventually  (Phase  4) 
broadcast  all  the  required  target  data  to  the  aircraft  while 
it  was  in  flight  over  the  target  area.  This  requirement, 
coupled  with  the  prohibition  against  changing  any 
hardware  in  the  aircraft,  was  a  major  factor  in  the 
evolving  design  of  the  ETE  Test  synthetic  environment. 

The  requirement  called  for  providing  data  on  more  than 
five  thousand  targets  to  VSTARS  on  board  the  aircraft. 
By  using  the  DIS  entity  state  protocol  data  unit  (ESPDU) 
to  convey  this  information,  at  a  minimum  1152  bits  per 
ESPDU,  it  would  require  nearly  6  million  bits  of  data  to 
provide  a  single  update  to  the  aircraft 

The  DIS  standard  also  called  for  an  update  of  each 
entity’s  state  to  be  issued  if  a  predetermined  time  had 
elapsed  since  any  entity’s  last  ESPDU.  These  ESPDUs 
are  normally  referred  to  as  the  heartbeat.  This  was  done 
for  several  reasons,  none  of  which  apply  to  the  ETE  Test. 
The  default  length  of  time  between  heartbeats  is  five 


seconds.  In  addition,  DIS  uses  a  process  called  dead 
reckoning  to  limit  the  rate  at  which  simulations  must 
issue  updates  for  an  entity.”  [1]  On  a  regular  basis,  the 
simulation  compares  the  internal  model  of  an  entity  to  a 
simpler  model  based  on  a  specified  dead  reckoning 
algorithm.  When  the  two  models  deviate  by  a 
predetermined  amount,  the  simpler  model  is  updated  and 
an  ESPDU  is  broadcast  so  that  other  simulations  on  the 
network  can  update  their  model  of  the  entity. 

What  this  meant  in  terms  of  the  environment  was  that  we 
needed  a  minimum  effective  bandwidth  between  the 
ground  and  the  plane  if  we  were  to  transmit  ESPDUs  of 
around  1 .2  megabits  per  second. 

This  bandwidth  requirement  certainly  exceeded  any 
capability  currently  installed  on  the  aircraft,  or  even 
planned,  and  would  have  to  be  reduced  if  the  test  had  a 
chance  of  succeeding. 

It  also  would  require  a  major  portion  of  the  T1 
communications  lines  planned  for  the  conventional  WAN, 
and  if  broadcast  to  all  nodes,  as  specified  in  the  DIS 
standard,  could  cause  problems. 

Other  issues  with  the  DIS  standard,  such  as  the  coordinate 
system  used  in  DIS  and  the  multiple  conversions  required, 
were  present,  but  minor  in  comparison  to  the  bandwidth 
problem. 

4.  The  ETE  Test  Solution 

It  was  obvious  from  the  beginning  that  there  was  neither  a 
need,  nor  a  method,  to  transmit  this  amount  of  data  from 
the  ground  to  the  aircraft.  The  ESPDU  was  designed  to 
satisfy  everybody,  which  is  why  it  can  contain  at  least 
1 1 52  bits  of  data. 

VSTARS  had  not  yet  been  developed  at  this  stage  of  the 
synthetic  environment  design.  Therefore,  it  was  a  simple 
matter  to  include  in  its  design  a  data  packet  that  would 
contain  the  data  required  for  VSTARS.  This  data  packet, 
later  identified  as  the  VSTARS  data  packet  (VDP),  was 
formed  from  the  ESPDU  using  a  subsystem  of  VSTARS 
called  the  ground  network  interface  unit  (GNIU). 

The  function  of  the  GNIU  was  to  receive  the  ESPDUs 
from  the  WAN  and  process  them  into  VDPs.  This 
involved  converting  the  positional  data  from  world 
coordinate  system  to  the  topocentric  coordinate  system 
used  by  the  radar  and  a  reduction  of  both  positional  data 
and  velocity  data  to  16-bit  accuracy.  Also  included  was 
the  conversion  of  the  entity  orientation  data  to  a  16-bit 
orientation  in  the  two-dimensional  viewing  plane. 


The  end  result  was  a  192-bit  packet  (Table  4-1)  that 
provided  all  the  data  needed  to  insert  targets  from  the 
operational  scenario  into  the  radar  images  provided  by 
V STARS.  This  one  step  reduced  the  bandwidth 
requirement  down  to  200  kilobits  (Kbits)  per  second. 


Table  4-1.  VSTARS  Data  Packet  (VDP) 


|  VSTARS  Data  Packet 

Field  Size  (bits) 

Time  Stamp 

32 

Entity  ID 

16 

Entity  Type 

Category 

8 

Subcategory 

8 

Specific 

8 

Extra 

8 

Entity  Linear  Velocity 

X-Comp. 

16 

Y-Comp. 

16 

Z-Comp 

16 

Entity  Location 

X-Comp. 

16 

Y-Comp. 

16 

Z-Comp 

16 

Entity  Orientation 

X-Comp. 

8 

Y-Comp. 

8 

VDP  Size 

192  bits 

5.  Tuning  the  Environment 

Phase  2  of  the  test  was  conducted  in  a  laboratory 
environment  and  was  in  effect  a  rehearsal  of  Phase  4, 
where  we  would  be  required  to  link  the  GNIU  and  ANIU 
with  satellite  communications. 

Phase  2  allowed  the  ETE  Test  team  to  characterize  the 
ESPDU  flow  over  the  lifetime  of  the  test  event.  Five 
scenarios,  each  lasting  six  hours,  were  used  in  Phase  2 
and  would  be  used  during  the  Phase  4  operational  test. 
Though  different,  each  exhibited  certain  characteristics 
that  proved  we  would  have  a  problem  during  Phase  4. 

The  first  problem  encountered  was  the  fact  that  we  had 
gotten  carried  away  in  our  zeal  to  add  entities  to  the 
battlefield  and  now  had  Janus  populating  the  battlefield 
with  ten  thousand  entities.  The  second  problem  was  the 
fact  that  battlefield  actions,  and  accurate  simulations  of 
battlefield  actions,  are  incoherent.  In  all  of  the  scenarios 
there  were  periods  of  intense  activity  that  created  bursts 
of  hundreds  of  ESPDUs  per  second.  There  were  also 
periods  where  it  was  necessary  to  check  to  see  if  the 
scenario  was  still  running. 


Noticeably  missing  from  the  VDP  is  the  dead  reckoning 
parameter  field  (320  bits)  from  the  ESPDU.  Dead 
reckoning  is  performed  by  the  air  network  interface 
(ANIU)  subsystem  of  VSTARS.  The  ANIU  receives  the 
VDP  from  the  GNIU  and  performs  dead  reckoning  on 
those  entities  with  a  velocity  other  than  zero.  It  then 
stores  the  data  on  each  entity,  moving  and  nonmoving,  in 
VSTARS’  target  database.  It  was  determined  during  the 
design  phase  of  VSTARS  that  simple  first-order  dead 
reckoning  was  adequate,  and  it  was  written  into  the  code 
for  the  ANIU. 

The  final  design  step  taken  to  reduce  the  bandwidth 
requirements  was  to  make  the  heartbeat  period  adjustable 
within  Janus.  Bandwidth  requirements  were  not  the  only 
consideration  in  doing  this,  as  the  broadcasting  of  a 
thousand  ESPDUs  a  second  was  no  small  task.  Simply 
extending  the  heartbeat  period  to  two  minutes  would 
reduce  the  bandwidth  requirements  for  the  air-to-ground 
link  to  less  than  9  Kbits  per  second.  This  act  was  made 
possible  because  the  ETE  Test  synthetic  environment  was 
a  closed  environment  specific  to  a  test,  and  no  one  would 
be  allowed  to  enter  the  environment  without  prior 
coordination. 

The  overloading  of  portions  of  the  network,  due  to  the 
broadcast  of  so  many  ESPDUs,  was  avoided  by  designing 
the  network  so  that  only  VSTARS  received  them. 


Our  first  approach  to  solving  this  problem  was  to  throw 
the  DIS  standards  on  heartbeat  out  the  window.  VSTARS 
stores  the  location  of  each  entity  within  its  area  of  interest 
in  a  target  database.  The  location  of  each  target  will 
remain  the  same  until  new  data  are  received  from  the 
ANIU.  Targets  that  are  moving  are  updated  by  the  dead 
reckoning  function  of  the  ANIU.  Targets  that  are 
stationary  do  not  need  updating.  There  is  no  need  for  a 
heartbeat  except  to  initially  inform  the  target  database  of 
the  location  of  the  nonmovers.  If  an  entity  starts  moving, 
an  ESPDU  will  be  broadcast  and  dead  reckoning  will 
occur.  If  an  entity  stops,  an  ESPDU  will  be  broadcast 
with  zero  velocity  values  and  no  further  updates  are 
needed. 

This  was  implemented  by  modifying  the  scenarios  to 
include  an  initial  period  of  no  activity  whatsoever. 
During  this  period  the  heartbeat  is  turned  on,  at  a  rate 
within  the  satellite  link’s  capability,  and  the  starting 
position  of  each  target  is  stored  in  the  target  database. 
Once  the  target  database  has  the  starting  data  on  all  the 
entities,  the  heartbeat  is  turned  off,  the  scenario 
movement  is  started,  and  the  only  ESPDUs  broadcast  are 
those  that  indicate  a  change  in  speed  or  direction. 

This  effectively  reduced  the  number  of  ESPDUs 
broadcast  in  any  given  period  of  time,  as  most  of  the 
ESPDUs  previously  broadcast  were  the  result  of  the 
heartbeat. 


Further  tuning  of  the  scenarios  also  helped  reduce  the 
peak  protocol  data  unit  rates  by  spreading  out,  over  a 
period  of  time,  the  start  of  convoys  and  other  battlefield 
actions  that  generate  ESPDUs. 

The  final  stage  in  tuning  the  environment  was  to  look  at 
the  satellite  transmission  itself.  Extensive  testing  showed 
that  we  could  reliably  transmit  and  receive  up  to  thirty- 
four  VDPs  per  second.  Above  this  rate,  dropouts 
occurred  and  data  were  lost.  Unfortunately,  there  still 
existed  within  the  scenario  periods  when  the  ESPDU  rate 
exceeded  the  maximum  rate  that  could  be  reliably 
transmitted  via  the  satellite  link. 

The  solution  arrived  at  by  the  ETE  Test  team  was  to 
restrain  the  rate  of  transmission  of  the  VDPs,  to  ensure 
reliable  transmission,  and  to  buffer  the  excess  data.  In 
this  way,  periods  of  high  activity  would  be  spread  over 
several  seconds.  This  is  shown  in  Table  5-1 . 


Table  5-1.  VDP  Transmission  Rate 


Seconds 

1 

2 

3 

4 

5 

6 

7 

8 

9 

ESPDU/VDP 

6 

1 

8 

1 

2 

4 

3 

1 

1 

Generated  by 

8 

4 

9 

6 

2 

9 

6 

2 

Scenario 

VDP  Buffered 

3 

2 

0 

0 

0 

1 

2 

7 

0 

Awaiting 

Transmission 

8 

2 

2 

1 

I 

VDP 

3 

1 

2 

m 

Q 

n 

Transmitted 

0 

9 

6 

0 

0 

Via 

Satellite 

i 

Obviously,  this  adds  latency  to  the  transmission  of  the 
data  resulting  in  vehicles  turning  or  changing  speed 
several  seconds  late.  Two  factors  alleviated  this  problem. 

The  first  was  the  scope  of  the  exercise.  Referring  to 
Table  5-1,  in  the  first  three  seconds  data  for  thirty  entities 
are  delayed  one  second  and  data  for  eight  entities  are 
delayed  for  two  seconds;  this  was  out  of  10,000  entities 
with  several  thousand  moving. 

The  second  factor  was  the  radar  itself.  The  Joint  STARS 
radar  is  not  perfect.  Locational  error  exists  in  every 
detection  of  a  target.  A  target  moving  at  a  ground  speed 
of  40  kilometers/hour  will  only  travel  approximately  22 
meters  during  the  two-second  delay  described  above.  The 
radar  also  revisits  a  target  at  a  rate  that  is  measured  in 
seconds.  Therefore,  even  with  the  delay,  the  target  may 
well  be  updated  with  new  data  before  the  radar  revisits  it. 


Both  of  these  factors  resulted  in  no  observable  differences 
because  of  latency  in  the  radar  images  that  were  presented 
to  the  radar  surveillance  officers. 

6.  Verification  and  Validation  Issues 

The  ETE  Test  synthetic  environment  underwent  extensive 
testing  and  verification  and  validation  (V&V)  prior  to  the 
live  flights.  Details  are  available  on  the  JADS’  web  site, 
in  addition  to  previously  published  reports  and  papers 
presented  at  various  conferences  to  include  this  one.  It  is 
not  the  intent  of  this  paper  to  discuss  the  details  of  the 
V&V,  but  rather  to  discuss  a  phenomenon  associated  with 
using  satellite  transmission  to  transmit  simulation  data  to 
a  Joint  STARS  aircraft. 

The  phenomenon  is  simply  that  you  cannot  thoroughly 
test,  nor  V&V,  the  system  until  you  pay  the  big  bucks  and 
use  it  during  the  test.  The  T3  aircraft  used  in  the  ETE 
Test  is  such  a  costly  and  scarce  resource  that  every  flight 
counts.  There  would  not  be  a  flight  dedicated  only  to 
V&V,  even  if  we  had  been  willing  to  pay  for  it. 

The  testing  and  V&V  configuration,  shown  in  Figure  6-1, 
was  as  close  to  flight  conditions  as  it  was  possible  to 
duplicate.  System  integration  tests  and  V&V  were 
conducted  using  line-of-sight  transmission  and,  when 
satellite  time  was  available,  satellite  transmission. 


Figure  6-1.  Test  and  V&V  Configuration 


Despite  the  extensive  testing  conducted  prior  to  the  first 
flight,  it  was  still  impossible  to  verify  and  validate  the 
ETE  Test  synthetic  environment.  When  the  aircraft  took 
off,  the  environment  became  dynamic.  As  the  aircraft 
proceeded  toward  Fort  Hood  and  the  entity  starting 
positions  were  loaded  in  the  database,  the  relationship  of 


the  aircraft  was  constantly  changing  with  respect  to  the 
satellite. 

In  addition,  once  the  aircraft  arrived  on  station,  it  flew  an 
orbit  that  allowed  it  to  keep  the  mission  area  within  the 
radar  field  of  view.  As  the  aircraft  banked  during  the  turn 
at  each  end  of  the  orbit,  the  orientation  of  the  aircraft’s 
satellite  antenna  changed  with  respect  to  the  satellite. 
When  the  aircraft  banks  toward  the  satellite,  reception 
should  improve,  and  when  it  banks  away,  reception 
should  worsen.  Pretest  calculations  indicated  that  there 
was  a  possibility  that  data  would  be  lost. 

As  a  result,  part  of  the  actual  test  flights  involved  the 
V&V  of  the  satellite  link  under  operational  conditions. 
V&V  data  were  collected  simultaneously  with  test  data 
and  the  results  could  not  be  analyzed  until  after  the  test 
flights  were  completed.  The  V&V  results  showed  that 
data  were  lost  during  the  flight,  however  the  loss  was 
small  enough  that  it  did  not  affect  the  validity  of  the  link 
and  the  subsequent  mission. 

7.  High  Level  Architecture  (HLA) 
Challenges  and  Benefits 

Even  though  JADS  will  end  in  March  2000,  it  appears 
that  VSTARS  will  remain  as  a  valuable  legacy  product.  It 
has  been  adopted  by  the  Joint  STARS  Joint  Program 
Office  and  the  Air  Force  as  the  Joint  STARS  radar  model. 
It  will  be  used  for  the  joint  training  of  mission  crews  and 
common  ground  station  (CGS)  crews.  It  is  scheduled  for 
use  in  the  testing  of  the  CGS  and  is  being  considered  for 
the  testing  of  the  Block  20  E- 8. 

This  means  that  VSTARS  will  become  HLA  compliant  in 
the  near  future.  This  will  offer  challenges  and  benefits  as 
the  transition  is  made.  I  will  briefly  discuss  these  issues 
in  the  context  of  this  paper. 

Very  little  change  will  be  required  to  describe  the  ETE 
Test  synthetic  environment  in  terms  of  a  federation  and 
federates.  The  ETE  Test  SE  was  requirements  based. 
Each  object  in  the  environment  was  defined  in  terms  of 
required  actions  and  functions,  input  data,  and  output 
data. 

The  need  for  the  VSTARS  data  packet,  coordinate 
conversion,  the  broadcast  issues,  and  the  need  for 
controlling  the  flow  of  data  over  the  satellite  link  are  all 
reasons  for  the  use  of  a  runtime  interface  (RTI). 

In  addition,  much  of  the  control  of  the  environment  was 
ad  hoc  at  best.  We  actually  had,  at  one  point,  a  four, 
three,  two,  one,  start  your  simulations  take  place  over  the 


telephone.  Using  HLA,  most  of  this  exercise  control  can 
be  automated. 

What  then  are  the  challenges?  The  challenges  are  the 
same  as  were  present  in  the  ETE  Test  synthetic 
environment:  namely  latency  and  overload  of  the 
environment.  The  RTI,  by  its  very  nature,  is  bound  to  add 
some  latency  to  the  system.  Fortunately,  a  system  of  this 
type  is  very  tolerant  to  latency. 

Overload  is  a  challenge  for  at  least  two  reasons.  All  of 
the  potential  users  of  the  environment  have  said  that 
10,000  entities  are  great,  but  100,000  would  be  better. 
Will  the  RTI  handle  that  kind  of  load?  The  other 
challenge  is  bandwidth.  Even  HLA  cannot  overcome  the 
fact  that  the  pipe  is  only  so  big. 

8.  Conclusion 

The  ETE  Test  proved  that  ADS  could  be  used  to  test  Joint 
STARS  and  other  systems  in  their  operational 
environment  using  DIS.  It  also  showed  that  major 
modifications  had  to  be  made  to  the  DIS  standard  to  make 
it  work  under  the  conditions  of  the  ETE  Test.  It  would 
appear  to  the  author  that  HLA  offers  a  promise  of 
reducing  the  complexity  inherent  in  operational  tests  of 
complex  systems  of  systems  such  as  Joint  STARS. 
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